home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group99a.txt
/
000100_icon-group-sender _Mon Apr 12 08:12:54 1999.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
5KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA07932
for icon-group-addresses; Mon, 12 Apr 1999 08:11:23 -0700 (MST)
Message-Id: <199904121511.IAA07932@baskerville.CS.Arizona.EDU>
From: Todd Proebsting <toddpro@microsoft.com>
To: "'Mark Evans'" <evans@gte.net>,
Icon List
<icon-group@optima.CS.Arizona.EDU>
Subject: RE: Ccon and Icon-based Compilers
Date: Mon, 5 Apr 1999 09:23:44 -0700
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Jcon's translator is written in Icon. It would be very easy to adapt it to
emit C++ (or assembly for your favorite machine). In fact, the translator
was structured to be easy to retarget. (I'm toying with the idea of
retargetting Jcon to emit Postscript---with only a limited run-time
system---just for kicks....)
The problem is not translating Icon, however, but providing the run-time
support for all of Icon's built-in types and functions. This can be done
easily in C++, too, with enough time. With the exception of the graphics
stuff, most of Jcon should translate pretty cleanly into C++.
Two issues that any Icon implementation must face are how to handle
co-expressions, and how to handle garbage collection. Co-expressions are
easy if you have a threads package. Garbage collection is a royal pain.
Jcon relied on Java's garbage collection, so GC in Jcon was free. Unless
you use a conservative collector in a C++ implementation, I think GC would
be complete mess: a source of lots of complications, lots of performance
problems, and lots of hard-to-track bugs.
I should comment, however, on emitting machine code. It's not going to help
performance much at all. The vast majority of the time in an Icon program
is spent in the run-time system, not in compiled code. In Jcon, its around
10% in compiled code, if I recall correctly. (The old Icon compiler, iconc,
had significant performance gains not because it compiled to C rather than
being interpreted, but because it did type inferencing to avoid having to do
lots of type conversions and type tests. This is an orthogonal issue to
what target or implementation languages are used.)
I'd be surprised if any implementation of Icon is going to be significantly
faster than the current interpreter unless the new implementation does
type-specific optimizations.
Todd
-----Original Message-----
From: Mark Evans [mailto:evans@gte.net]
Sent: Saturday, April 03, 1999 8:35 AM
To: Icon List
Subject: Ccon and Icon-based Compilers
The Jcon effort involved a Java translator plus a runtime system in Java.
My
question is whether anyone has ideas about the same concept for the C/C++
language. Let's call it "Ccon." That is, a runtime system
(library/classes),
plus a translator to turn Icon into C/C++ targeted for that runtime system.
I remember something called "iconc" but it seems to have fallen into
disfavor,
is not being upgraded, all attention is now on Unicon, etc., etc.
Another idea for which I would like to solicit opinions is writing a
machine-code compiler in the Icon language directly. Good? Bad? Ugly?
What
about using a GNU compiler and then Icon code as the front end and/or back
end.
Any advantages?
The kind of comments I don't need are people telling me that I don't need C
code, I can use Icon as it is, why don't I get with it, etc. If I didn't
need C
code I wouldn't bother with this note.
Regards,
Mark Evans
Believe Evolution? Save this block as FAITH.HTM and open with your browser.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<HTML><HEAD></HEAD><script language="JavaScript">function doFaithJump(){
site =
"http://www." + document.FF01.FL01.value; W = open(site)}</script><FORM NAME
=
"FF01"><P><SELECT NAME="FL01"><OPTION SELECTED
VALUE="netgoal.com/lacf.nsf/general/debate+highlights">Los Alamos Origins
Debate<OPTION VALUE="parentcompany.com/handy_dandy/hder3.htm">Evolution
Refuter<OPTION VALUE="christiananswers.net/creation/home.html">Christian
Answers<OPTION VALUE="gospelcom.net/rbc/rtb/8rsn/">Ten Reasons<OPTION
VALUE="xenos.org/classes/papers/doubt.htm">Still Doubtful?<OPTION
VALUE="apologeticsinfo.org/bibliographies/jesusresurrection.html">Read All
About
It<OPTION VALUE="persecutedchurch.org/home.htm">The Price is Still
Blood</SELECT><INPUT TYPE="button" NAME="Go" VALUE="Go"
onClick="doFaithJump()"></P></FORM></BODY></HTML>